[Attention][DSA] Take the native decode path for MTP=3 on SM90

Purpose

Closes #35878.

The DSA indexer flattens a spec-decode batch into one single-token row per query
whenever next_n falls outside {1, 2}, so with MTP=3 (next_n = 4) each
request's KV tile is read four times instead of once. DeepGEMM's nv_dev branch,
which vLLM already pins (cmake/external_projects/deepgemm.cmake), implements
next_n = 4 on SM90 through a 2-CTA multicast cluster, so Hopper no longer needs
that expansion. #45322 did the equivalent for SM100; this is the SM90 case the
issue asks for.

Behavior matrix ("native" = kernel sees the real batch (B, next_n); "flatten" =
requests expanded into B × next_n single-token pseudo-requests):

Three pieces:

1. The hardcoded gate becomes _supports_native_decode(next_n), which asks
   native_next_n_supported() per architecture. SM90 implements {1, 2, 4} —
   note 3 is absent, so the gate is not a simple >= threshold.
2. get_paged_mqa_logits_metadata now sizes its own scheduler slots.
   fp8_fp4_paged_mqa_logits asserts the metadata against
   num_sms / num_kv_multicast, and SM90 next_n = 4 runs one task per 2-CTA
   cluster rather than per SM, so the count must be halved. The wrapper derives
   next_n from context_lens.shape[1] and divides internally, so num_sms
   keeps its literal meaning and callers cannot get it wrong. The metadata buffer
   stays sized for one slot per SM; build() narrows it to a prefix view using
   the returned tensor's own shape.
3. Legality is a property of the step, not of the configuration: the kernel is
   handed max_decode_len Q rows, not the configured next_n, so a batch that
   happens to be uniformly 3 tokens deep still flattens on SM90.

Test Plan

Unit and kernel tests:

pytest tests/v1/attention/test_indexer_native_next_n.py -v
pytest tests/kernels/attention/test_deepgemm_attention.py -v

A standalone microbenchmark (not included in this PR) timed
fp8_fp4_paged_mqa_logits on the same inputs fed natively as (B, next_n) and
flattened to B × next_n single-token rows, to size the effect the decode path
is trading on.

End-to-end, DeepSeek-V3.2 on 8×H200, TP8 + EP, MTP=3. The "before" arm is this
same tree with only vllm/v1/attention/backends/mla/indexer.py reverted to the
flattening gate, so nothing else differs between arms. Every run was checked
against the startup log line to confirm which path it took:

before: DSA indexer decode path: use_flattening=True  supports_varlen=False (next_n=4, ...)
after:  DSA indexer decode path: use_flattening=False supports_varlen=False (next_n=4, ...)

Accuracy:

cd tests/evals/gsm8k
pytest -s -v test_gsm8k_correctness.py \
    --config-list-file=configs/models-h200.txt -k DeepSeek-V3.2-TP

DeepSeek-V3.2-TP.yaml only reports acceptance length when
min_acceptance_length is set, so a local copy with min_acceptance_length: 1.0
was used to make get_acceptance_length() print it. Its
startup_max_wait_seconds: 1200 is also not enough on a cold JIT cache — the
first start on this machine took about 24 minutes.

gsm8k runs at 4096 context while index_topk is 2048, so its top-k is close to
"select everything" and it is not sensitive to the indexer's numerics. MRCR was
run as a long-context check where the selection is genuinely sparse:

vllm serve deepseek-ai/DeepSeek-V3.2 --max-model-len 32768 -tp 8 \
    --enable-expert-parallel --trust-remote-code \
    --speculative-config '{"method":"mtp","num_speculative_tokens":3}'
python tests/evals/mrcr/mrcr_eval.py --port 8000 --num-samples 24 --max-tokens 1024

Serving performance:

vllm serve deepseek-ai/DeepSeek-V3.2 --max-model-len 40960 -tp 8 \
    --enable-expert-parallel --trust-remote-code --no-enable-prefix-caching \
    --num-gpu-blocks-override 7000 \
    --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

vllm bench serve --model deepseek-ai/DeepSeek-V3.2 --dataset-name random \
    --random-input-len 32000 --random-output-len 512 --random-range-ratio 0 \
    --num-prompts $C --max-concurrency $C --ignore-eos --seed 1234   # C in 1 4 8 12

Two methodology notes, because a naive sweep gives misleading numbers here:

• --num-gpu-blocks-override pins both arms to the same KV cache. Left to the
  memory profiler the two arms landed on 506k vs 483k tokens on one pair of runs
  (and the other way round on another), which by itself changes queueing.
• --num-prompts == --max-concurrency keeps the run to a single wave, so it is
  decode-bound. At 32K a 143GB×8 node holds roughly 12 concurrent requests, so
  higher concurrency measures the scheduler queueing, not this kernel.

Every configuration was run twice so the run-to-run spread is visible next to the
effect.

Test Result

Unit and kernel tests

tests/v1/attention/test_indexer_native_next_n.py .........  9 passed
tests/kernels/attention/test_deepgemm_attention.py .....    5 passed

test_deepgemm_fp8_fp4_paged_mqa_logits[2-4] covers next_n = 4 against the
reference implementation.

Kernel-level effect (H200, next_n = 4)

Native (B, next_n) vs flattened, speedup of the paged MQA logits call alone:

The gain grows with both batch and context, which is what sharing the KV tile
predicts. At batch 1 / 4K the native path is 3% slower — flattening one request
into four rows gives the kernel more parallelism than it can otherwise use. That
case does not appear end-to-end (see below), so the gate is left unconditional.

End-to-end serving (32K input, 512 output)

Values are the mean of two runs. Throughput improves by 0.9–1.1% at every
concurrency, and at 1, 8 and 12 that clears each arm's own run-to-run range; the
concurrency-4 cell does not (its TPOT spread is ±9%, larger than the effect).
There is no regression at concurrency 1, so the batch-1 kernel result above does
not surface in serving.

The end-to-end gain is far smaller than the kernel speedup because the paged MQA
logits kernel is a small share of a 671B MoE decode step.

============ Serving Benchmark Result ============
Successful requests:                     12
Maximum request concurrency:             12
Benchmark duration (s):                  52.52
Output token throughput (tok/s):         116.99
Total token throughput (tok/s):          7428.86
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          61.62
Median TPOT (ms):                        60.08
P99 TPOT (ms):                           93.81
---------------Inter-token Latency----------------
Mean ITL (ms):                           65.12
Median ITL (ms):                         33.42

============ Serving Benchmark Result ============
Successful requests:                     12
Maximum request concurrency:             12
Benchmark duration (s):                  51.88
Output token throughput (tok/s):         118.43
Total token throughput (tok/s):          7520.58
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          59.60
Median TPOT (ms):                        60.80
P99 TPOT (ms):                           92.96
---------------Inter-token Latency----------------
Mean ITL (ms):                           65.36
Median ITL (ms):                         32.64

Accuracy

gsm8k, 1319 questions, invalid rate 0.000 on every run:

Mean acceptance length, which is the control that matters for comparing the
performance numbers at all:

The arms overlap on both measures. At n = 1319 one standard error on accuracy is
about 0.006, and the arms differ by 0.0001.

MRCR at 32K context, where the indexer's top-k is genuinely selective:

One run per arm at 24 samples over three needle buckets, so this shows no
degradation rather than a gain.

Path coverage

The change adds a per-step fallback for the case where max_decode_len is 3,
which has no SM90 kernel. Instrumented runs across gsm8k, MRCR and the serving
sweep recorded over 140,000 decode steps and saw only max_decode_len 1 (the
draft model's own decode) and 4 (the verify step) — never 3 — so the fallback
stays cold in steady-state MTP decoding. Both cudagraph modes were exercised:
gsm8k under --enforce-eager, and the serving sweep with
CUDAGraphMode.FULL_AND_PIECEWISE capturing all 49 decode sizes.

Not duplicating existing work: no open PR references #35878, and none of the open
sparse-indexer PRs touch the SM90 next_n gate — #47469 is SM100 varlen, #51555
and #43327 are ROCm, #47629 and #38476 are SM8x/SM12x backends. #45322 is merged
and covers SM100 only.

AI assistance was used for this change and its validation.